home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload Trio 2 / Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO / dir24 / mb1705.zip / BIDMID.DOC < prev    next >
Text File  |  1993-12-28  |  30KB  |  591 lines
  1.  
  2. This is an initial draft of a "full" explanation of BIDs, MIDs, LIDs,
  3. along with message authentication and integrity issues.
  4.  
  5. ------------------------------------------------------------------------
  6.  
  7. Some comments - I hope that other bbs code authors will also comment ...
  8.  
  9. > ONCE UPON A TIME MESSAGES HAD NO IDENTIFIER, OTHER THAN THE SENDER,RCVR
  10. > AND TITLE.
  11.  
  12. Not really true.  They always HAD an identifier (the message number and the
  13. originating bbs callsign) becuase that is what sysops used to talk about them
  14. - just as soon as there were TWO sysops in the world (k1ojh and w0rli, joined
  15. a month later by k1bc).  This did not cause any problem as there was only one
  16. choice of bbs code and not very many bulletins (like two or three per
  17. day).  A bit later headers were added, and they provided the unique
  18. identification for the message.
  19.  
  20. > MESSAGES WERE EASILY DUPLICATED BECAUSE OF THAT, ESPECIALLY WHEN THE FLOOD
  21. > DESIGNATORS WERE USED.
  22.  
  23. Flood designators did not exist until roughly 18 months later.    They were
  24. invented by wa7mbl.
  25.  
  26. > A SMART BYTE SMASHER CAME UP WITH THE IDEA TO GIVE A SPECIAL ID FOR BULLITENS
  27. > (FLOOD MESSAGES) AND THROUGH THE EVOLUTION OF THIS CONCEPT A SPECIAL ID FOR
  28. > PERSONAL MESSAGES WAS ALSO BEGUN.
  29.  
  30. Not quite true.  Nothing different about B or P messages.  Those that were
  31. given a BID, had one, those that were not given a BID did not have one.  Later
  32. on, ALL B messages were assigned a BID, whether the user gave them one or not.
  33. This was done after discussion between wa7mbl and w0rli.  The changes were
  34. easy to make:  there were only two choices of bbs code - mbl or rli.  We
  35. talked about the changes, and made them.  There was usual difficulty in keeping
  36. changes in synch, of course.
  37.  
  38. > SO A "BID" IS A BULLITEN ID (FLOOD) AND A "MID" IS A MESSAGE ID (PERSONAL/NTS).
  39.  
  40. Not at all.  A MID is the identifier for any message:  B, P, or T.  The BID is
  41. a SECOND identifier assigned to some messages.    Originally, it was ONLY
  42. assigned by the user when he entered the message.  Later the bbs codes (we
  43. still have only two) assigned them automatically, if the user did not specify
  44. them.  A BID can be assigned to any message.  Some BBS codes prohibit
  45. assigning a BID to T or to P messages, some allow it.  There is not yet a
  46. standard on how to handle all the cases.  The BID identifies the BODY or
  47. CONTENT of the message, the MID identifies the originator of a PARTICULAR
  48. message.
  49.  
  50. > NOW THE QUESTION REMAINS... WHAT IS THE "STANDARD" FOR EACH?
  51. > WITH ALL CURRENT BBS SYSTEMS TODAY, IT SEEMS THAT EVERY MESSAGE (FLOOD OR
  52. > PERSONAL) IS GIVEN A NUMBER.    THIS NUMBER IS THE SEQUENTIAL ORDER OF
  53. > GENERATION OR ARRIVAL OF EACH MESSAGE AT THAT BBS.
  54.  
  55. For some bbs codes, that is correct.  For others it is not.  But in all cases,
  56. there is SOME unique way to identify each message entered at a bbs, and that
  57. unique identifier plus the bbs callsign is all you need to identify the source
  58. of the message.  Strange as it might seem, we bbs code authors actually talk
  59. to each other about these issues, and try to resolve them.
  60.  
  61. > IN FBB (AND IN MOST SYSTEMS IT SEEMS), IF THE GENERATOR OF THE MESSAGE DOES NOT
  62. > GIVE A SPECIFIC ID TO THE MESSAGE THEN THE BBS AUTOMATICALLY USES THE MESSAGE
  63. > NUMBER COMBINED WITH THE BBS CALL SIGN TO CREATE AN ID FOR THE MESSAGE.
  64.  
  65. For FBB and for MOST of the other BBS codes, that is exactly what happens.
  66. For some BBS codes (e.g.  some versions of NOS, some codes written in Germany,
  67. some unix based codes) other kinds of identification are used.
  68.  
  69. > NOW ACORDING TO THE ABOVE, IF THE MESSAGE IS A FLOOD THEN THE ID IS A BID,
  70. > AND CONVERSLY IF THE MESSAGE IS A PERSONAL/NTS THEN THE ID IS A MID.
  71.  
  72. No.  The message always has a MID.  This is how we talk about the source of
  73. the message - where it was entered, what number it had at that bbs.  The
  74. message may ALSO carry a BID, which may happen to be the same characters as
  75. the MID, or may be different.  The BID identifies the CONTENT, not the
  76. particular message.  Several messages may be originated at different bbs
  77. systems, each with the same BID.  Each has a different MID.  It is the BID
  78. that allows for multiple entry of the same information at different locations
  79. on the network, without having duplicates of that same information appear.
  80.  
  81. > LOOKING THROUGH THE MESSAGES AT THIS BOARD LEADS ME TO CONCLUDE THAT UNLESS
  82. > THE ID IS USER GENERATED THAT THERE IS NO DIFFERENCE BETWEEN A BID AND A MID.
  83.  
  84. Did you look into the database, or rely on what the bbs code chose to show you
  85. on the screen?    How did it display the MID and the BID when both were present
  86. (e.g.  an AMSAT ORBS-xxx bulletin for example)?
  87.  
  88. > LOOKING THROUGH THE PERSONAL MESSAGES THAT HAVE PASSED THROUGH THIS BOARD,
  89. > I FIND THAT MY NEIGHBORS' BBS (AA4RE TYPE, VERSION UNKNOWN) DOES NOT ASSIGN
  90. > AN ID TO A PERSONAL MESSAGE (BID/MID WHAT HAVE YOU) AND THIS MESSAGE DOES
  91. > NOT HAVE AN ID UNTIL MY FBB RECIEVES THE MESSAGE AND GENERATES ONE USING THE
  92. > MESSAGE NUMBER (AS REPORTED IN THE R: LINE) AND THE CALL OF MY NEIGHBORS BBS.
  93. > EXAMPLE: #####_BB4AA
  94.  
  95. The ID is there all along.  This is the MID.  The header is how we send the
  96. MID from one system to another.  This is how it has been since the begining -
  97. at least once we HAD headers - and that is another story.
  98.  
  99. > FROM THE REST OF THE PERSONALS THAT I CAN READ HERE, ALL THE OTHERS EITHER
  100. > HAD THIS TYPE OF ID TO BEGIN WITH OR WERE GIVEN ONE IN THE SAME MANNER.
  101. > SAME WITH THE BULLITENS, #####_BB4XZ IS THE ID OF THE MESSAGE.
  102.  
  103. > NOW TO EXPLAIN MY CONFUSION, I THOUGHT A "MID" WAS THE SEQUENTIAL NUMBER OF
  104. > ASSIGNMENT BY EACH BBS AS THE MESSAGE PASSED THROUGH.  THE "22354@N7WVZ"
  105. > AS REPORTED IN THE R: LINE RIGHT AFTER THE DATE/TIME, NOT THE 26557_W0RLI
  106. > AS ASSIGNED BY THE ORIGIONATING BBS.    I THOUGHT THAT THEN A BID AND A MID
  107. > WOULD ONLY BE THE SAME AT THE ORIGIONATING BBS, EX: 22458@N7WVZ, 22458_N7WVZ.
  108.  
  109. The MID is (typically) the message number and callsign AT THE ORIGINATING BBS.
  110.  
  111. > SO, NOW IT SEEMS THAT A "BID" AND A "MID" ARE THE SAME THING, ONLY QUALIFIED
  112. > BY THE DESTINATION OF THE MESSAGE THEY ID.  IS THIS TRUE??  IF SO WHAT'S THE
  113. > FUSS??
  114.  
  115. Not the same thing at all.  They often LOOK alike, but the software USES them
  116. differently, for different reasons.  The MID identifies a particular message.
  117. The BID identifies a particular message BODY.
  118.  
  119. > PLEASE REPLY IF THIS IS INCORRECT OR IF YOU CAN EXPLAIN THE PURPOSE OF THE
  120. > DISTINCTION.
  121.  
  122. Consider one of those AMSAT ORBS bulletins.  It's BID is the typical ORBS-xxxx
  123. but it's MID is the callsign of the originating BBS and the message number at
  124. that BBS.  It is done this way so we can tell where that bulletin was put into
  125. the system.
  126.  
  127. > WITH FBB, THE DISTINCTION IS MOOT AS FAR AS I CAN SEE AS THE FORWADING OCCURS
  128. > NOT BY THE BID ALONE, BUT BY THE HROUTE.  IF THE MESSAGE HAS BEEN PASSED BUT
  129. > THE ACK HASN'T BEEN RECEIVED THEN THE PROPOSAL IS RESENT AT THE NEXT FORWARD
  130. > TIME AND IS THEN REJECTED BY TO RECEIVING BBS BECAUSE THE BID IS ALLREADY
  131. > LOGGED AND THE MESSAGE IS THERE.  IF THE MESSAGE DIDN'T GET COMPLETED THEN
  132. > THE BID ISN'T LOGGED AND THE PROPOSAL IS ACCEPTED.  BULL OR PRIVATE, DOES
  133. > NOT MAKE ANY DIFFERENCE, EXCEPT THAT FBB LOOKS AT THE "P" OR "B" AND FORWARDS
  134. > THE PRIVATES FIRST.
  135.  
  136. And now we get to the interesting part.
  137.  
  138. > FURTHER, IF THE MESSAGE IS A BULL THEN IT GETS PROPOSED TO EACH BBS THAT I
  139. > HAVE SET UP TO RECEIVE BULLS, IF IT'S PRIVATE THEN IT GETS PROPOSED TO
  140. > EACH BBS WITH THAT HROUTE IN IT'S FORWARD FILE.  EAST GOING HROUTES GO EAST
  141. > AND/OR TO THE CLOSEST HUB/HF/INTERNET BBS THAT I KNOW OF.
  142. > THIS ALL SEEMS TOO SIMPLE TO BE MAKING AN ISSUE OVER A "BID" AND A "MID"
  143. > HAVING THE SAME STRUCTURE/CONTENT.  WHY CARE AS LONG AS IT'S UNIQUE ENUF THAT
  144. > THE CHANCE OF ANOTHER BBS GENERATING AN EXACT BID/MID TO ANOTHER MESSAGE IS
  145. > INFANTESIMAL?  IF THE BID USES THE ORIGIONATING BBS CALL THEN THAT IS UNIQUE
  146. > ENUF, DON'T YOU THINK?  THEN ALSO IF THE MESSAGE IS AN ARRL BULL THEN THE
  147. > BID IS SET TO BE UNIQUE FOR THAT BULL (ARRL0243 OR WHAT EVER THE FORMAT IS)
  148. > AND THEN WHEN 3 DIFFERENT STATIONS GENERATE THAT BULL WITH THE SAME BID THE
  149. > MESSAGE FORWARDS TO EVERY BBS THAT DOESN'T HAVE IT AND ISN'T DUPED AT THE
  150. > ONES THAT ALLREADY HAVE IT (WHAT EVER THE SOURCE).
  151.  
  152. And what happens with personal messages?  In particular, what happens if a
  153. personal message has to be sent BACK to a system you got it from.  This will
  154. happen, for example, when a personal message is mis-addressed, and needs to be
  155. forwarded BACK the same route that you got it from.  If the bbs you forward it
  156. to rejects it because it's MID has been seen before, that message will be
  157. LOST.
  158.  
  159. This is why BIDs and MIDs are different:  the bbs code must handle them in
  160. different ways.  This choice was made way back in the beginning.  The options
  161. are to suffer a few duplicates (because they will not be rejected) or to lose
  162. a few messages (because they will be rejected).  The original choice was to
  163. suffer a few duplicates rather than to hazard the loss of personal messages.
  164.  
  165. What happens in our network today?  Both duplicates and lost messages occur,
  166. becuase there is not yet a standard - not even a proposed standard - covering
  167. this situation.
  168.  
  169. --------------------------------------------------------------------------
  170.  
  171. Why are bbs messages and fifty dollar bills different?
  172. Fiftry dollar bills each have a unique identifier, don't messages?
  173.  
  174. For messages, we have copies.  I have a copy of the bulletin you sent, for
  175. example - not the original which is probably still on your system.  So we need
  176. more identifiers.  We need to be able to talk about that original, and the
  177. copy I have, and the copy WB7VMS has (I got it from WB7VMS).
  178.  
  179. So we clearly need LIDs (Local IDs) which identify each copy.  The MID is
  180. simply the LID at station of origin.
  181.  
  182. Now some bulletins have an additional feature:    the "same" bulletin is entered
  183. in several places.  One example is the ORBS information.  The copy that I get
  184. may have originated at N7DUO by KT7H or may have originated at PA0BBS by
  185. DL0WPK.  Either one carries the same text, and we don't want duplicates.  Thus
  186. there is a BID to identify the message text.  Each of those two messages also
  187. has a MID (showing where it originated) and a LID (it's identity at my
  188. system).  I will reject duplicate copies no matter where they were originated,
  189. because the BID will be the same even though the MID is different.
  190.  
  191. So we have three identities required for a message:
  192.  
  193. 1. BID - unique identifier of the message CONTENT.
  194. 2. MID - unique identifier of the individual message at it's point of entry.
  195. 3. LID - unique identifier of a copy of the message.
  196.  
  197. ----------------------------------------------------------------------------
  198.  
  199. From: brianbr77@aol.com
  200. To: bbs_authors@Arasmith.COM
  201. Date: Wed, 08 Dec 93 21:22:34 EST
  202.  
  203. The LID is the identification of the message on each system where it resides.
  204. There is little need for this ID to be considered anywhere outside of that
  205. system, EXCEPT the LID from the originating system which can serve as its
  206. Message ID for inter-system forwarding.
  207.  
  208. The BID came about for one simple reason - we had a need to be able to enter
  209. identical message texts for general interest ARRL and AMSAT materials from
  210. multiple entry points without getting dupes.  So a 'generic' ID system was
  211. created for the various bulletin types.  The system works very well.
  212.  
  213. Now obviously each of the initial copies of these bulletins, though the text
  214. is identical, is a different message (each has a unique LID/MID from its
  215. originating system) unique from the others.  In reality they are transported
  216. using their BID so that when the copy from Toronto runs into the copy from
  217. Plattsburg (NY) in Erie (PA) they stop dead.
  218.  
  219. Non-flood messages are no different in their passing except that they are
  220. passed along the (theoretically) most direct route to the addressed BBS.  Now
  221. the 'deferred disconnect' feature of NR/TN/BPQ generates quite a few
  222. duplicates (I still shudder when I think about my 'message from Hell - 4486
  223. bytes, a P to me from a ZS6 that kept timing out in the Hudson River Valley
  224. corridor and eventually I actually received 40 some odd copies and Joe, WA2SPL
  225. my mail hub killed at least 20 more!) Getting an ID on them will cure much of
  226. it.
  227.  
  228. The real problems with a MID passing for non-flood is the worry about loss of
  229. message - my system marks them D and the sysop needs to look at it and cause
  230. it to be killed or otherwise handled.
  231.  
  232. The other objection is the re-routing.    Once again I say that a simple
  233. ReMailing routine which strips the message down to its text body and ReMails
  234. it with new LID/MID to where ever it should go solves the problem and even
  235. older codes don't kill it.
  236.  
  237. The last objection is how to treat T messages.    We cannot treat them like
  238. flood-messages or we will ultmately have the same message on 4 BBSes and may
  239. actually deliver four copies to some unsuspecting recipient.  Maybe we should
  240. simply pass T-messages sans IDs or pass them with the LID of the passing
  241. system so that dupes from system A to system B are eliminated.
  242.  
  243. I see the following problems that need to be resolved before we can make a
  244. spec for 'M1' ('M' is out there now, ill defined, so whatever we decide should
  245. become 'M1')
  246.  
  247. (1) How do we define what is a 'flood bulletin' - on my system a flood
  248. bulletin is any @-address for which I have a support file called address.FLD
  249. (like USBBS.FLD) - how do others do it?  I realize there is a flaw in my
  250. system if I get a message presented SB USERS @ VTNET $TEST001 I store it, save
  251. the BID and mark its 'route' NONE.  I have to do an LR NONE to find it or else
  252. if I see it in passing on general lists.  If I anticipated this 'mistake' I
  253. might have a translate entry that was *@VTNET *@VTBBS and of course it would
  254. get translated and VTBBS.FLD would kick in.
  255.  
  256. (2) Hank and I spoke on the phone and we both agreed that the spec and most of
  257. us are a little vague about non-flood bulletins, that is, suppose I want to
  258. send a bulletin to USERS@W0RLI.OR.USA.NA from VT.  Some systems simply because
  259. it is a B will want to treat it like a flood message but will get confused
  260. because W0RLI is not a distribution (actually a distribution of 1!) I think
  261. most system will handle this OK now, but mostly by accident!  I really think
  262. we must stop thinking that a message being a 'flood message' is determined by
  263. type being 'B' - we need a different criteria, or else we must overhaul how we
  264. handle P - that is we would have to send it from here as SP
  265. USERS@W0RLI.OR.USA.NA and when it gets to Hanks he has to determine to display
  266. it as B or untyped because it is to USERS as opposed to SYSOP ......
  267.  
  268. (3) we need to agree upon passing T messages - just use LID for specific
  269. inter-system transfer.    If the other guys gets it Ok we can in good faith kill
  270. the T message on our system and it is now his worry?  The LID used will only
  271. stop dupes between you and that system ...  if he gets another copy from
  272. elsewhere so be it
  273.  
  274. (4) we need to agree on 'valid' message types, forced typing, and what to do
  275. when we get a message type we do not have - I personally think it should be
  276. open ended - though once we get to implementing a USENET style 'news group'
  277. the need for 'types' to further sub-divide messages goes away.  Unfortunately
  278. for now we must consider typing as it influence the way some codes handle
  279. things.
  280.  
  281. <brian>
  282.  
  283. --------------------------------------------------------------------------
  284.  
  285. Date: Tue, 16 Nov 93 18:54:04 EST
  286. From: ka2bqe@ka2bqe.#nwvt.vt.usa.na (Brian B. Riley)
  287. Message-ID: <12522_KA2BQE> (Underhill Ctr, VT)
  288. To: sysop@usbbs
  289. Subject: IDs Explained
  290.  
  291. In theory there are three different IDs for messages to be dealt with;
  292.  
  293. LID - local ID - some designation of a message on any given system usually
  294. simply a number, usually 32 bit long and often only represented as a 16 bit
  295. unsigned plus @BBS.  EVERY message has a local ID on each system
  296.  
  297. MID - message ID - a way to identify a message to certify its uniqueness
  298. through the system to prevent duplication of the message - by implication this
  299. applies to any message.  It is generally the LID of the message from its
  300. orginating system.
  301.  
  302. BID - bulletin ID - a special case of MID.  The idea being that often the same
  303. message (like AMSAT or ARRL bulletins) would be orginated for distribution
  304. purposes from multiple sources.  So the idea was that using some set naming
  305. convention they would be named generically rather than using the generic LID
  306. format for the MID.
  307.  
  308. The BID idea was orginated by Jeff WA7MBL.  It worked well enough that many of
  309. us decided to apply it to non-flood messages.  And then the problems began.
  310. At various times various of the BBSes have had the following decision
  311. criteria;
  312.  
  313. - if the Send line presents a $ plus a string - its is automatically a
  314. bulletin and a flood route is looked for - that had private messages stopped
  315. dead since the normal H-route never matched any flood route
  316.  
  317. - any message sent type P was not a flood message and had its BID stripped out
  318. - and was then sent back out without BID so that the first sucker to accept it
  319. instantly got blamed for 'changing BIDs'!
  320.  
  321. - some systems say that if it is type B it must be a flood bulletin, if it is
  322. a P its not - so you cannot do an SB USERS @ K1XXX.MA.USA.NA.
  323.  
  324. - then we have the problems of ID formats, the usual default format for a
  325. message-ID is <16 bit unsigned integer in decimal> <_> <orginating BBS
  326. callsign> But, since IDs, particularly BIDs can be of any construct, there is
  327. no valid grounds for altering/disregarding IDs based upon format, but some BBS
  328. codes do!
  329.  
  330. - there is the problem that we have more and more systems running two or three
  331. computers and needing a way to identify their system (i.e.  12345_K1RQG1)
  332. whihc is fine if you are not a 2x3 callsign.  Others have taken to making the
  333. ID with <-> instead of <_> and so on.  The spec calls for 12 chars.  It is a
  334. problem we code writers need to look into.
  335.  
  336. Hank's RLI is the one BBS code that has really held out on implementing
  337. message ID handling.  But his code, like most others can be forced to add an
  338. ID to any message just by typing SP KA2BQE @ KA2BQE $.    What makes it funny is
  339. that all RLI code will properly pass the IDs presented to it ...  and what
  340. makes it hilarious is that the one system that noone wants to say anything bad
  341. about will pass IDs to an RLI system - it is not supposed to send an ID on a
  342. non-flood message unless the 'M' is in the SID!
  343.  
  344. The primary objection to M handling for non-flood messages is that if a
  345. message gets to a system and has to be re-addressed it may get nailed on the
  346. way back out.  I addressed this problem in the ReMailer I created for PRMBS,
  347. stripping out all of the old headers and assigning a new ID (the one and only
  348. time ID strip and re-assignemnet is justified!).  Frank Warren, KB4CYC created
  349. a package called RMAILER (currently v2.13 avaiable from many HamBBses) based
  350. upon my RMAIL/DISTRIBUTION/ReMail concepts that will work with FBB and any
  351. other system that will handle standard MBL format import/export files.    So in
  352. my rarely so humble opinion the point is moot.
  353.  
  354. I hope this answers a lot of the questions that are floating around.
  355.  
  356.   <brian>
  357.  
  358. ------------------------------------------------------------------------
  359.  
  360. Just one thing I noticed.  Since WA7MBL did BIDs back in 1985, it has been the
  361. case that all "flood messages" must carry a BID, even if addressed SP.  This
  362. was done to cover the case of SP SYSOP.  In about 1987, most existing codes
  363. followed this rule, as long as the P message had a distibution.  It was also,
  364. since 1985, permitted to add a BID to P messages, even if sent to a callsign,
  365. and not to a distribution.  All the problems began to appear in about
  366. 1991-1992 when new codes did not follow the exact same rules as mbl/rli/bqe
  367. used, and when aa4re began to transmit MIDs instead of BIDs with the S command
  368. for messages which did not have a distribution.  This caused the ensuing
  369. BID/MID confusion which has lead to the present "disaster".
  370.  
  371. That's the reason my recent code generates BIDs with a different format than
  372. usually used to display MIDs - so it will be obvious which is which.
  373.  
  374. The one bug I found with the extensive forwarding tests was that MSYS, FBB,
  375. and AA4RE could be set up to ignore the BID presented on the S command.  They
  376. would accept the message, and then forward it without any BID at all.  If the
  377. message happened to be to a distribution (a flood message such as SP SYSOP @
  378. WW for example), a dup would be generated just as soon as that message hit any
  379. system that requires BID for flood messages - as all must ...
  380.  
  381. How do we cure this?  I have no idea.  MSYS needs to be fixed so it will never
  382. drop a presented BID, and Mike is working on that.  I've not heard any
  383. positive response from Jean-Paul or from Roy (except that Roy does not yet
  384. appear to understand that he needs to hardwire this stuff - sysops are not
  385. capable of setting things up right).
  386.  
  387. Say some station forwards to me a message:  SP ALL @ ALLOR $1234_N1QRM Is that
  388. "1234_N1QRM" a BID, or a MID?
  389.  
  390. Say that same station forwards to me:  SP SYSOP @ WW $AMSAT_TEST That is
  391. probably a BID ...  anyway, it LOOKS like one.
  392.  
  393. Say that same station forwards to me:  SB WANT @ USA $1234_N7QSY It's a BID -
  394. by definition.    Nobody would argue about that.
  395.  
  396. Note that I have no "M" in my SID - so nobody will forward something with
  397. "$MID" to me.
  398.  
  399. Now what happens if someone forwards to me:  SP SYSOP @ USA
  400.  
  401. I need to add a BID to that message.  It is a flood message.  Without a BID,
  402. there will be millions of dups - it will ping-pong back and forth around the
  403. network forever.
  404.  
  405. OK you say, so lets just put a BID on every message.  Yes, we thought of that
  406. way back in 1985 - there is a problem.    A message that must travel back the
  407. same path it came will be rejected and lost.  This is not good (if you have
  408. ever run a major HF forwarding system, you will understand - we toss stuff
  409. back and forth as the band conditions change).
  410.  
  411. So the original design was to allow for flood messages - you could tell which
  412. ones they were since they had a "$BID" when they were forwarded to you - and
  413. to allow for backtracking by all other messages.  This worked if:  1) any
  414. system that originated a flood message put a BID on it, and 2) no system ever
  415. dropped a BID or changed a BID.
  416.  
  417. All was well (or at least "all worked resonably well") until AA4RE decided to
  418. do the "M in the SID" thing.  That's what started the mess we are in now.
  419.  
  420. I won't even comment on "land line forwarding" - it is not ham radio.
  421.  
  422. Hope this history is helpful - it explains how we got to where we are.
  423.  
  424.  
  425.    ...    Hank
  426.  
  427. Date: 04 Dec 93 23:21
  428. Message-ID: <18400@N0ARY> (12736@W0RLI)
  429. From: KA2BQE@N0ARY
  430. To: W0RLI
  431. X-msgtype: P
  432. Subject: PRMBS MID/BID Handling
  433.  
  434. From: brianbr77@aol.com
  435. To: bbs_authors@Arasmith.COM
  436. Date: Sat, 04 Dec 93 18:04:52 EST
  437.  
  438.  I have posted this before, but I will reiterate it as it seems to work very
  439. well.
  440.  
  441.  I assign an ID to every message created upon a PRMBS system. I generate it
  442. using the format 12345_KX1XXX,
  443.  the number being derived by masking out the upper 16 bits of the 32 bit long
  444. it used as the LID. If the
  445. user specifies an ID on the command line I take that if its is not a dupe. I
  446. am changing that since the
  447. only code not supporting 'M' is RLI and his code passes the presented ID more
  448. perfectly than many
  449. of the systems that do!
  450.  
  451.  When forwarding I do not  'present' an ID on the send line for non-flood
  452. messages to any system
  453. that does not have an 'M' in the SID feature list. If I am presenting a
  454. non-flood message with
  455.  an ID capable system I mark it as 'D'upe if it is rejected. I do not kill
  456. it.
  457.  
  458.  Now when I am recieving messages via forwarding. I take note of the
  459. 'presented' ID, if it is not
  460.  a dupe I OK it and accept the message. I then look down the R: headers. I
  461. take note of anything
  462. presented on an R: line with a $: and  remember the last one I got. I then
  463. look for a
  464. "Message-ID: <...> field and if present I overide anything that I might have
  465. gotten from the R:/$:
  466.  
  467.    Now it gets tricky. If no ID was presented, I take whatever was
  468. 'recovered' from within and
  469. use it. If an ID was presented and what was recovered match, I just go on, if
  470. what was presented
  471.  and what was recovered are different I then check the recovered value
  472. against my ID file
  473.  and if present the message is stored with a status 'D'upe, if it wasn't in
  474. the ID file I record it and
  475.  the mark the ,essage status '?' for sysop review. Either way no flood
  476. pointers get generated.
  477.  I generally can catch any dupe bulletin that has a trace of its orginal BID
  478. in it, as well as any
  479.  duplicate P-messages that orginated on another PRMBS system and many FBB or
  480. REBBS systems.
  481.  
  482.   This system has been in use now for several years, with the last part about
  483. the D/? being in use for 8 months. I have had no complaints of any problems
  484. and my sysops tell me it really does catch a lot of the garbage.
  485.  
  486.   The last part is the 'return path' problem on re-addressed non-flood
  487. messages with IDs.
  488.  It is quite simple. The ReMailer that Frank Warren, KB4CYC coded from my
  489. RMAIL/ROSEDIST
  490.  code handles all remailing. Recording entire orginal text body of message,
  491. the stripping out
  492.  R: headers synthesizing an barebones RFC-822 header and sending the message
  493. back out
  494.  to its re-addressd destination. - NO ID or R: headers to trip it! RMAILER
  495. v2.13 that Frank wrote
  496.  will work with FBB and with any system that can do MBL format import export.
  497.  
  498.   After our heated discussions last spring I revamped PRMBS so that it does
  499. no ID changing or
  500.  'reconstruction' It will only add an ID to a non-IDed message
  501. if it can find an ID somewhere
  502. inside it. I call this 'recovered' to keep the idea separate from
  503. what Roy and some others do.
  504.  
  505.    I for one have to agree with DFD and some others that 'regeneration' of
  506. BIDS should not
  507.  be allowed. It is too fraught with danger.
  508.  
  509.   <brian>
  510.  
  511. -------------------------------------------
  512.  
  513. Message security issues ...
  514.  
  515. As a general comment:  if someone creates a "more secure system", someone else
  516. will figure out how to break it.  Any scheme that relies, for example, on
  517. authentication of the connected station only at connect time can be easily
  518. broken.
  519.  
  520. Thus, authentication is required on a per-packet basis.
  521.  
  522. (If it is not obvious why this is true, I'll be glad to provide the scenario,
  523. think about intercepting an uplink to a netrom node AFTER the password has
  524. been accepted - takes only a stronger signal on the uplink.  This technique
  525. was used in N.    Cal.  to regain control over a node pair after it's sysop made
  526. it do some "real bad things").
  527.  
  528. So I maintain that we have at least four requirements to consider:
  529.  
  530. 1.  Data integrity.
  531.  
  532. A packet channel normally gaurantees this, as does CLOVER.  AMTOR, ASCII LL
  533. links do not.  This is more an operational issue than a technical issue.
  534.  
  535. 2.  Authentication of the connected station.
  536.  
  537. I believe we cannot possibly gaurantee this.  We CAN add more "stuff" to the
  538. connect protocol, for example a "netrom like challange/response sequence".  I
  539. propose we reserve feature letter P for this - if P is not already in use.
  540. This protocol addition would at least gaurantee that the initial few packets
  541. came from the station you thought they came from.  It provides no gaurantee
  542. that the following packets were not provided by some other station.  Unless we
  543. change to protocols that provide authentication on a per-packet basis, we
  544. cannot gaurantee authenticity of data received.
  545.  
  546. 3.  Protocol transparency.
  547.  
  548. This we can achieve if we choose to.  The issue here is "all systems knowing
  549. how to talk to each other by adhering to a common standard." The problem of
  550. BIDs truncated to seven characters falls in this realm.  We have an initial
  551. standard.  Every author has reservations about some part of that standard.  We
  552. could, however, all code to that standard, and thus gaurantee a minimum
  553. capability for all systems.  Additional capabilities can be negotiated via SID
  554. feature letters.  All bbs codes handle this pretty well.
  555.  
  556. 4.  Traceability.
  557.  
  558. Without 1.  and 3., we cannot gaurantee traceability.  Think for a bit about a
  559. "bad bbs system" that chooses to alter the tracking information.  No problem
  560. providing the correct CRC (if CRC protection is used).    Header strippers,
  561. header "normalization" code, header munging by noisy LL connections, character
  562. translation by AMTOR all cause this to happen now.  In most cases, the damage
  563. is done only by buggy code.  It could, however, be done intentionally (see
  564. comment below).  Most bbs codes provide the sysop with log files which record
  565. all significant transactions on their message base.  Messages can be traced
  566. both by their headers and by the traces they leave in log files.  This
  567. technique was used in New England to track down a bootlegger way back in 1985
  568. - even though the message headers were altered, the log files of the bbs in
  569. the area were examined, and the message trail reconstructed from transaction
  570. time stamps.
  571.  
  572. > My concern over sysops or others altering msg content or fake msgs is very
  573. real and this issue has not been the subject of public debate.    I recognize
  574. that no system is completely foolproof but currently there are no intergity
  575. controls.  You or I or any sysop could easily receive a letter from the FCC
  576. alleging that we allowed an illegal msg into the system and be completely
  577. innocent.
  578.  
  579. > If I release a bltn, I would like to have some assurance that the content of
  580. that bltn will be maintained.
  581.  
  582. I think this is not possible.
  583.  
  584. > Anyone can take any bltn, change the contents and send it back out with
  585. entirely different text.  Or originate a bltn and substitute another callsign.
  586.  
  587. This has already been done, with the headers jimmied to make station of origin
  588. and first few forwarding hops look realistic.  It is very simple to do ...
  589. Didn't get all that much hate mail from it though.
  590.  
  591.